Multiple worlds/pipelines #328

AnthonyTornetta · 2023-02-14T23:07:30Z

This closes #221 by allowing multiple worlds to be used in parallel.

Reasoning

Currently, bevy_rapier restricts its usage to a single world per game, which is limiting in many situations, despite rapier itself having no restriction on the amount of worlds it supports. This PR changes RapierContext to instead store a list of RapierWorlds which hold what RapierContext used to hold. Each world is addressable be a unique WorldId, which can be attached to any entity via the PhysicsWorld component. The physics world simply stores the world's id.

Goal

The goal of this PR was to add support for any number of worlds to bevy_rapier with minimal breaking changes to projects already using this that are content with only one world. The only changes that will be made to such projects are as follows:

raycast calls will now need the DEFAULT_WORLD_ID provided as the first argument and you will need to call .expect("The default world should always exist") before using their result.
If you provided custom arguments to the RapierContext, you will instead need to do:

RapierContext::new(RapierWorld {
  your custom stuff,
  ..Default::default()
})

Similarly, to access those items you now have to do context.(get_world/get_world_mut)(DEFAULT_WORLD_ID).expect("Default world should exist").field_you_wanted
Some other things may need to be adjusted to first get the world, but these were the main ones that would affect the most projects.

Example

I have provided a 3d example of the multiple worlds in action in multi_world3.rs.

Each of those platform/block pairs is in its own physics world, where they do not interact with each other.

A GIF of a cube changing its world every 3 seconds and moving between platforms in different worlds found in change_world3.rs:

PhysicsWorld

This is a component that may be attached to any entity where you want to specify its world. If this component is omitted, the entity will be added to the DEFAULT_WORLD_ID world, which is present in every game. If this component is attached, the entity will be added to the specified world. If the component is modified, the entity should switch the world that it is in to reflect the id it was changed to.

To add or remove a world, just use RapierContext::add_world and RapierContext::remove_world respectively.

AnthonyTornetta · 2023-03-07T23:55:04Z

This has been updated to bevy 0.10

Also added world_id in event

AnthonyTornetta · 2024-05-29T18:56:33Z

I've made some updates while updating this branch to not have any conflicts, two of which will change the public API:

WorldId ID to events (as mentioned above):
- The WorldId is now included in the CollisionEvent enum. This will cause the public API to change once more, but since it's pretty easy to ignore this field I don't think it's a huge problem.
Changed where gravity is defined
- The integration rework proved problematic for this PR, since the RapierContext resource has been restructured. One of the things that I had to move to make understandable was the gravity field. This is now stored in each world, rather than in the RapierContext. As such, you'll have to do either RapierWorld::set_gravity or RapierWorld::with_gravity, the latter being a builder-like method that returns self.

Vrixyz · 2024-06-24T08:08:12Z

Thanks again for your ongoing discussion on this topic !

For information, I'm starting to study bevy_rapier API in order to offer a few improvements, mainly RapierContext usage, but I'd love to support your use-case with those API improvements.

The exact details of these improvements are still being worked on, and I'd like to familiarize myself with the design implications and understand in practice the changes necessary for supporting multiple worlds, so I'll be exploring on my own branch from master.

For multi-world feature, I will probably transition RapierContext to be a Component, and explore SystemParams to offer good ergonomics for single world users.
In parallel, I will study bevy_xpbd to compare approaches.

I think this particular Pull Request is unlikely to be merged as-is, but thanks again for the work which will prove handy to compare approaches, and the discussions to find a good path forward !
I'm only stating my own feeling, and to manage expectations, I look forward to further discussions on this not trivial feature 😄.

Vrixyz · 2024-06-25T09:52:34Z

src/pipeline/events.rs

-    pub collision_events: RwLock<EventWriter<'a, CollisionEvent>>,
-    pub contact_force_events: RwLock<EventWriter<'a, ContactForceEvent>>,
+    pub collision_events: &'a mut RwLock<Vec<CollisionEvent>>,
+    pub contact_force_events: &'a mut RwLock<Vec<ContactForceEvent>>,


That's a good change in my opinion 👍 , it helps with support for multi world and we don't need a whole EventWriter there anyway.

Vrixyz · 2024-06-25T09:56:26Z

src/pipeline/events.rs

        colliders
            .get(handle)
            .map(|co| Entity::from_bits(co.user_data as u64))
            .or_else(|| self.deleted_colliders.get(&handle).copied())
-            .expect("Internal error: entity not found for collision event.")


I imagine that's a good change to allow users to come back from errors, but if we're returning None, isn't that a sign we did a system ordering mistake ?

AnthonyTornetta · 2024-06-25T14:11:46Z

I agree that moving forward with the "componentization" of RapierContext is a good choice. Given that is the direction you're going, I agree that merging these changes in would be pointless, given that many would have to be redone anyway. I would be happy to help out with this architectural shift if you would like any, and if you have questions you want to ask me outside of github, I'm in the dimforge discord server and my username is Cornchip.

I will continue to keep this branch updated for now, since I am using it in my own project. Thanks for taking interest in supporting multiple worlds! I'm sure a lot of people (besides me) will appreciate it.

Vrixyz · 2024-06-26T07:21:48Z

src/plugin/context.rs

+                events.is_some(),
+                hooks,
+                time,
+                sim_to_render_time,


I'm not sure sharing SimulationToRenderTime between all worlds will still yield useful results. I think we'd want it to be specific to each world.

example from dimforge#328 Co-authored-by: Anthony Tornetta <25857049+AnthonyTornetta@users.noreply.github.com>

Vrixyz · 2024-06-27T08:40:25Z

src/plugin/systems/worlds.rs

@@ -0,0 +1,111 @@
+//! Systems responsible for interfacing our Bevy components with the Rapier physics engine.


Thanks for putting those in a separate file 👍 The comment seems a bit off but I'll look into the rest of the code for my own multi-world support attempt :)

Vrixyz · 2024-06-27T09:23:07Z

src/plugin/systems/rigid_body.rs

+/// assuming the child is hit by the full velocity of the parent instead of `parent vel - child vel`.
+///
+/// This will not change the bevy component's velocity.
+pub fn sync_vel(


I assume this is to address #383

This could be stripped out of this PR for sure, it is not at all necessary for the worlds changes.

Vrixyz · 2024-06-27T09:38:26Z

src/plugin/systems/worlds.rs

+///
+/// If this fails to happen, weirdness will ensue.
+pub fn on_add_entity_with_parent(
+    q_add_entity_without_parent: Query<(Entity, &Parent), Changed<Parent>>,


I imagine we should filter for any handles or existing PhisicsWorld, this query risks iterating through a lot of entities (probably especially UI)

I absolutely agree, I believe when I made that I was just worried about missing any child hierarchy changes. IE: If this entity's children were in the physics simulation, I would want to change its children to reflect the new world they should be a part of. I don't think this is an especially common usecase, I just didn't want any unexpected functionality to be present.

Vrixyz · 2024-06-27T12:35:46Z

src/plugin/plugin.rs

-                    .before(TransformSystem::TransformPropagate),
+                    .before(TransformSystem::TransformPropagate)
+                    .after(systems::sync_removals),


interesting change, do you remember the rationale ?

If I remember correctly, I did that to prevent any of the init_* systems from running before sync_removals had finished. I believe I was running into inconsistencies in that regard without this being set, causing stuff to be removed after it had been re-added to the proper world.

AnthonyTornetta · 2024-10-20T19:33:07Z

Closing in favor of #545

AnthonyTornetta added 8 commits February 10, 2023 12:48

Refactored context to have multiple worlds

d671d7a

Supporting multiple worlds

cdfafa4

Adding example + reworking to be faster. Disabled custom events for now

2010f94

Multiple worlds work together

d6fae15

Improved example

55f2745

Added docs

1cb6d8c

Clippy --fix

2eed336

Added support for new changing worlds

23f8046

This was referenced Feb 14, 2023

Feature Request: Multiple pipelines? #221

Open

Infinite Universe AnthonyTornetta/Cosmos#57

Closed

AnthonyTornetta added 4 commits February 15, 2023 11:36

Making imports work

83816cd

Fixed imports

4b99318

Removed error when removing DEFAULT_WORLD_ID

e5af080

Fixed improper swapping of worlds

a0dfceb

AnthonyTornetta changed the title ~~Multiple worlds~~ Multiple worlds/pipelines Feb 22, 2023

AnthonyTornetta added 11 commits February 23, 2023 01:08

testing please ignore

d1dd55d

Fixed incorrect after

c534146

Made BodyWorld changes bubble down to children.

8b32f80

Testing ReadMass changes

b36c5dc

Added debug statements to master

455de13

More debug prints

a1a0a8f

Fixing bubble up

1461aa6

Commented out useless code

ce8c335

Debugging

d6d378f

Merge remote-tracking branch 'upstream/master' into multiple-worlds

e52085c

Merge branch 'multiple-worlds'

ed07c1b

AnthonyTornetta added 3 commits March 8, 2023 22:38

Got bevy events working

87161ab

Clippy

4fb4e7b

Merge branch 'dimforge:master' into master

bc49212

AnthonyTornetta added 13 commits May 29, 2024 10:41

Merge remote-tracking branch 'upstream/master' into multiple-worlds

e737b9e

Merge character controller

30b61be

Merge joints

939fbab

Merge remove

0f081c0

Merge writeback

ca5d879

Merge collider

46d266a

Merge rigid_body

2b5ec29

Merge mod

70d0f8d

Merge world

197fd34

Clippy fix

f744377

Reworked world syncing to be more reliable

5bcb4d3

Fixed ambiguous system ordering that could cause issues

f2ddf29

Also added world_id in event

Added gravity builder method to make creation of worlds easier

0b66c3f

Added missing scale multiply

643f8b3

Vrixyz reviewed Jun 25, 2024

View reviewed changes

Vrixyz reviewed Jun 26, 2024

View reviewed changes

Vrixyz added a commit to Vrixyz/bevy_rapier that referenced this pull request Jun 26, 2024

multiple worlds working + example

95562e9

example from dimforge#328 Co-authored-by: Anthony Tornetta <25857049+AnthonyTornetta@users.noreply.github.com>

Vrixyz added a commit to Vrixyz/bevy_rapier that referenced this pull request Jun 26, 2024

multiple worlds working + example

4fd9746

example from dimforge#328 Co-authored-by: Anthony Tornetta <25857049+AnthonyTornetta@users.noreply.github.com>

Vrixyz added a commit to Vrixyz/bevy_rapier that referenced this pull request Jun 26, 2024

multiple worlds working + example

24fd036

example from dimforge#328 Co-authored-by: Anthony Tornetta <25857049+AnthonyTornetta@users.noreply.github.com>

Vrixyz reviewed Jun 27, 2024

View reviewed changes

Vrixyz mentioned this pull request Jun 27, 2024

Rapier context as a Component #545

Merged

AnthonyTornetta closed this Oct 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multiple worlds/pipelines #328

Multiple worlds/pipelines #328

AnthonyTornetta commented Feb 14, 2023 •

edited

Loading

AnthonyTornetta commented Mar 7, 2023

AnthonyTornetta commented May 29, 2024

Vrixyz commented Jun 24, 2024

Vrixyz Jun 25, 2024

Vrixyz Jun 25, 2024

AnthonyTornetta commented Jun 25, 2024

Vrixyz Jun 26, 2024

Vrixyz Jun 27, 2024 •

edited

Loading

Vrixyz Jun 27, 2024

AnthonyTornetta Jun 27, 2024

Vrixyz Jun 27, 2024

AnthonyTornetta Jun 27, 2024

Vrixyz Jun 27, 2024

AnthonyTornetta Jun 27, 2024

AnthonyTornetta commented Oct 20, 2024

		@@ -0,0 +1,111 @@
		//! Systems responsible for interfacing our Bevy components with the Rapier physics engine.

Multiple worlds/pipelines #328

Multiple worlds/pipelines #328

Conversation

AnthonyTornetta commented Feb 14, 2023 • edited Loading

Reasoning

Goal

Example

PhysicsWorld

AnthonyTornetta commented Mar 7, 2023

AnthonyTornetta commented May 29, 2024

Vrixyz commented Jun 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AnthonyTornetta commented Jun 25, 2024

Choose a reason for hiding this comment

Vrixyz Jun 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AnthonyTornetta commented Oct 20, 2024

AnthonyTornetta commented Feb 14, 2023 •

edited

Loading

Vrixyz Jun 27, 2024 •

edited

Loading